Reference to Appendices A to D
Microfiche Appendices A to D, consisting of 6 sheets and 279 frames, are a part of the present disclosure and each is incorporated herein by, reference in its entirety. A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
1. Field of the Invention
The invention generally relates to generally to computer network management, and in particular to managing heterogeneous computer network elements.
2. Description of Related Art
Over the years, the organization of computer systems has changed dramatically. The concept of a large computer center with a single large computer to which all users bring their work is obsolete. The single large computer has been replaced by a large number of separate but interconnected computers that form a computer network.
There are many types of computer networks including Local Area Networks (LANs), Metropolitan Area Networks (MANs), Wide Area Networks (WANs), Wireless Networks, and Internetworks. An internetwork is a collection of interconnected networks and is sometimes called an internet. The Internet is a specific worldwide internet. The widespread popularity of the Internet has resulted in yet other types of computer networks such as intranets and extranets.
A computer network includes both hardware and software. Typically, a network architecture is defined in terms a set of layers and protocols that define the communication between hardware and software in a computer as well as the communication between computers on the network. One widely used network architecture is the Transmission Control Protocol/Internet Protocol (TCP/IP) Reference Model. TCP/IP is well-documented and is known to those of skill in the art.
As computer networks have become more common, a number of new devices were introduced to facilitate communications between network computers including local and remote bridges, multiprotocol routers, distributed hubs, and switching hubs. Similarly, the number and diversity of computer platforms, both hardware and software, connected to a network increased. Typically, as each new product was introduced, a new user interface was introduced to those that managed the computer network. Each new user interface has its own terminology, commands, and navigational metaphor.
Hence, in the past few years, as computer network complexity has grown exponentially, computer network management challenges have grown similarly. The networks are too complex and too critical for any single person to manage alone. Even simple networks are typically managed by more than one network administrator.
To assist in the management of TCP/IP computer networks, a Simple Network Management Protocol (SNMP) was implemented. However, today, SNMP is used in proprietary network environments including Netware IPX/SPX, DECnet, AppleTalk, and SNA environments.
SNMP is an industry standard for managing heterogeneous TCP/IP-based computer network elements from a single management application. SNMP defines the protocols and message formats which are used to communicate between the management application and the computer network element. With SNMP, a network manager can configure computer network elements and monitor computer network performance and status. SNMP, version 1 is defined by several standards documents that include:
RFC 1155, "Structure and Identification of Management Information for TCP/IP-based Internets," May, 1990; PA1 RFC 1157, "A Simple Network Management Protocol (SNMP)," May 1990. PA1 RFC 1212, "Concise MIB Definitions," March, 1991; and PA1 RFC 1213, "Management Information Base for Network PA1 The network management protocol is an application protocol by which the variables of an agent's MIB may be inspected or altered. Communication among protocol entities is accomplished by the exchange of messages, each of which is entirely and independently represented within a single UDP datagram using the basic encoding rules of ASN.1. A message consists of a version identifier, a SNMP community name, and a protocol data unit (PDU). A protocol entity receives messages at UDP port 161 on the host with which it is associated for all messages except for those which report traps (i.e., all messages except those which contain the Trap-PDU). Messages which report traps should be received on port 162 for further processing. An implementation of this protocol need not accept messages whose length exceeds 484 octets. However, it is recommended that implementations support larger datagrams whenever feasible.
Management of TCP/IP-based Internets: MIB-II," March 1991. Each of the above documents is incorporated herein by reference to demonstrate the level of skill in the art for SNMP. As used in the standards document, RFC stands for Request For Comment.
A computer network 100 (FIG. 1), that is managed using SNMP, includes, for example, a management station 110, a workstation 120, a bridge 130, a router 140, and a printer 150. Network 100 also could include, for example, personal computers, repeaters, and hubs. SNMP is a client-server based application protocol. Management station 110 executes a SNMP manager application 115 that communicates with SNMP agent processes 121, 131, 141, and 151.
Specifically, SNMP manager 115 communicates with client processes, i.e., agent process 121 on workstation 120, agent process 131 on bridge 130, agent process 141 on router 140, and agent process 151 on printer 150 using SNMP. An agent computer process must be programmed for each of the computer network elements, and the actions that are to be taken must be specifically programmed for each computer network element.
Each of agent processes 121, 131, 141, and 151 monitors and controls the operation of the computer network element containing the agent process, i.e., elements 120, 130, 140, and 150 respectively, by maintaining a data base of objects 122, 132, 142, and 152, respectively, called the Management Information Base (MIB). The MIB reflects the status of the managed computer network element. Each of the agent processes 121, 131, 141, and 151 responds to network management requests from SNMP manager 115. An agent process can also send unsolicited messages, called trap events, to SNMP manager 115 to apprise manager 115 of network events. Manager 115 maintains statistics that define the operation of network 100 in MIB 112.
The SNMP standards define proxy agents that may be used to access management information from a remote device. A common usage of proxy agents is to translate protocols when the remote device does not support SNMP.
SNMP uses well-established standards to define the format, content, and database structure of management information objects that are stored by the agent process and passed between SNMP manager 115 and the agent. These objects are carried in packets called protocol data units (PDUs) and contain operating parameters, statistics, and control information for the element and its components. The objects (variables) comprise the MIB. The current version of the MIB definition as defined by the standards body is MIB-II. Any SNMP management process can access MIB-II data.
The MIB may be extended beyond the standard set of objects to include objects specific to the agent by incorporating a private vendor-specific enterprise MIB. MIB objects are grouped according to functionality and are categorized in a tree-like data structure. The tree is comprised of a root, branches, and leaf nodes The leaf nodes represent MIB object instances and can be located by traversing the tree as deeply as possible. To simplify the traversal process, each branch at the same level in the tree is assigned a lexicographically ordered number. Thus, each node in the tree is representable by a sequence of period-separated numbers, where each number is associated with a branch level. The sequence of numbers is known as the object identifier (OID). FIG. 2 illustrates a portion of the MIB-II tree and how object identifiers are assigned. From FIG. 2, one can determine that the object identifier for the system group is 1.3.6.1.2.1.1.
RFC 1157, "A Simple Network Management Protocol (SNMP)" describes the operation of SNMP by stating:
Compliance with SNMP, version one standard (See RFC 1157, page 16) requires that all implementations of SNMP support five PDUs, i.e., GetRequest-PDU, GetNextRequest-PDU, GetResponse-PDU, SetRequest-PDU, and Trap-PDU. The five PDUs are described in detail in TABLE 1.
TABLE 1 __________________________________________________________________________ Standard PDU's __________________________________________________________________________ GetRequest Issued by the management station to the agent to retrieve information from the MIB GetResponse Issued by the agent after receiving a GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU to send MIB object values or responses to the management station GetNextRequest Issued by the management station to traverse the agent's MIB tree by moving sequentially from one object value(instance) to the next without knowing the precise name of the object SetRequest Issued by the management station to modify and store information within the agent's MIB Trap An asynchronous (unsolicited) message issued by the agent to the management station to report a significant event. __________________________________________________________________________
By using these operators, a SNMP manager application can communicate with managed nodes to identify the nodes, and to determine statistical information, such as network traffic flow through a given computer network, for the network.
SNMP trap events allow the SNMP agent to initiate communication with management applications when a significant (serious) network event takes place. The significant trap events are defined in RFC 1157. By default, all SNMP agents generate Trap-PDUs for the events shown in TABLE 2.
TABLE 2 ______________________________________ Events Resulting in Traps ______________________________________ Cold Start An agent initialization or re-initialization which may affect the values of objects has occurred Warm Start An agent re-initialization which does not affect the value of any object has occurred Link Down The agent has discovered a failure in one of the communication links of its configuration Link Up A communications link in the agent's configuration has just become activated Authentication The agent has received a protocol message that Failure was not properly authenticated with the correct community name (this trap may be suppressed upon request) Neighbor Loss The agent has discovered that a neighbor is down Enterprise The agent has experienced a vendor-specific event ______________________________________
In contrast to trap events, polling events are proactive requests made by management station 110 to elicit information from the agent. A common network management technique called "trap directed polling" is for the management station to wait for a trap event and then poll for more information regarding that event. This method minimizes the impact on managed elements and network bandwidth. However, since traps are sent unreliably, some degree of polling is still required as a backup precaution.
Access to an agent is controlled by a community name. Every agent is configured to recognize one or more community names, and to provide the appropriate level of access to SNMP managers based on the community name that the managers include in their messages.
The community relationship between agents and managers defined by the community name is used to administer the MIB and to provide the agent information on where to send a trap. There are three levels of access to MIB objects: read-only (object value can be read but not modified), read-write (object value can be read or modified), and write-only (object value can be modified but not read). The level of access which the agent allows for its MIB objects is determined by comparing the community name provided in the SNMP message with that defined by the agent. If the two names match, access is given. A separate community name is defined for read and write accesses. The most common community names are public (access given to all management stations) and private (no access allowed). Community names are not considered passwords because community names cannot make any guarantees regarding the command (message) with respect to its origin, its integrity, its delivery, or its privacy. More information regarding community names is contained in RFC 1157.
While SNMP was designed to simplify network management, this has not be the case. To make SNMP successful, every device vendor must provide tools to monitor and troubleshoot their devices, or alternatively get some other company that supplies a management system to include support for their particular device. In general, the communication of vendor specific MIB objects among heterogeneous elements is problematic.
The challenge is clear. How can a group of network managers efficiently manage a constantly changing and growing network which is composed of a wide array of heterogeneous elements, that are produced by different vendors, and that support many different platform types? Any solution must be simple, flexible, robust, secure, collaborative, and most importantly has to work.